\section{Disadvantages of our technique}

The proposed technique is fairly complicated.  In order for all the
advantages to be had, the callee must be represented in such a way
that multiple versions can be created, depending on different
information provided by each caller.  On the other hand, most of the
benefit of this technique can be obtained with a limited amount of
such flexibility.  Bypassing argument parsing in the presence of
optional or keyword parameters will already provide great benefits.
For this benefit to be as useful as possible, it is advantageous to
compile a callee in two parts; one part that allows for its parameters
to be positioned in any places (registers or stack frame locations)
that makes the remaining code as fast as possible, and one part that
parses arguments from their default locations into those places.  The
callee can then generate code for the snippets that moves the
arguments passed by the caller to those final places.

The garbage collector must not reclaim snippets that are currently in
use, and ``in use'' can mean that a callee has an activation record on
the call stack, so that the snippet can not be reclaimed until the
activation record is removed from the stack.  As a result, a
modification to the garbage collector is required, and code for
garbage collectors is notoriously hard to get right.

The technique involves the creation of two unconditional \emph{jump}
instructions; one from the core code of the caller to the snippet and
another one from the snippet back to the core code of the caller.
These additional instructions must be executed, which may use up
processor cycles.  However, on most modern processors, unconditional
jumps are very fast \cite{10.5555/3207796}.

Finally, there may be some slightly increased probability of
contention in the instruction cache, due to the fact that snippets are
allocated wherever the global memory manager can fit them.

%%  LocalWords:  callee
